对Hypervisor进行模糊测试

阅读量385635

|评论4

发布时间 : 2020-07-29 10:30:24

本文是翻译文章

译文仅供参考，具体内容表达以及含义原文为准。

作者：Demesne@360云安全研究院

对软件进行模糊测试是发现漏洞的重要途径之一。Hypervisor（或VMM）是云环境中的核心部件，用于实现虚拟化、构建虚拟机，功能包括CPU虚拟化、内存虚拟化、IO虚拟化、硬件设备模拟等，常见的Hypervisor如QEMU-KVM、Xen、Vmware EXSi、Vmware workstation、Virtualbox等。由于Hypervisor功能与架构的复杂性，直接采用普通软件的fuzz方法对其进行模糊测试难以得到很好的效果。 本文选取几项对Hypervisor进行模糊测试的相关成果进行综述，fuzz对象以QEMU/KVM为主。在此仅抛砖引玉，如有问题或建议欢迎随时交流~

注：本文为综述类文章，大部分图片选取至论文原文，可参见正文中引用标志。

以时间先后排序，几项相关成果如下： ① When virtualization encounter AFL-A Portable virtual device fuzzing framework with AFL(2016) ② VDF: Targeted Evolutionary Fuzz Testing of Virtual Devices(2017) ③ 使用syzkaller对vhost内核模块进行模糊测试(2018) ④ 使用AFL fuzz virtio-blk&SPDK(2019) ⑤ Qtest结合libfuzzer对QEMU设备进行FUZZ(2020) ⑥ HYPER-CUBE: High-Dimensional Hypervisor Fuzzing(2020)

将以上分为四个大类，分别为：一、 fuzz多个Hypervisor的通用方法： ① When virtualization encounter AFL: A Portable virtual device fuzzing framework with AFL(2016) ② HYPER-CUBE: High-Dimensional Hypervisor Fuzzing(2020)二、纯QEMU硬件模拟IO fuzz： ③ VDF: Targeted Evolutionary Fuzz Testing of Virtual Devices(2017)三、QEMU-KVM/virtio fuzz： ④ 使用AFL fuzz virtio-blk(2019) ⑤ Qtest结合libfuzzer对QEMU设备进行FUZZ(2020)四、vhost内核模块 fuzz： ⑥ 使用syzkaller对vhost内核模块进行模糊测试(2018)

正文

① When virtualization encounter AFL: A Portable virtual device fuzzing framework with AFL(2016)[1] Jack Tang and Moony Li @ Trend Micro, Blackhat Europe 2016 本文提出一个针对虚拟硬件设备的fuzz系统，特点为可移植性和代码覆盖率指导，适用于开源和闭源的Hypervisor。系统由三部分组成：定制的guest BIOS（Customized BIOS System，CBS）、设备控制客户端（Device Control Clients，DCC）和集成的AFL-fuzz。

1.定制的guest BIOS（称其为CBS组件）：比操作系统更轻量级，是与设备进行IO交互的接口。 a) 功能：发现fuzz的目标设备；初始化设备工作环境；运行一个内存和IO操作的代理服务器（Memory and IO space Operation Proxy Server,MIOPS） b) 实现：基于Seabios定制。 BIOS一般有三个运行阶段：开机自检阶段（初始化内部状态、外部接口、检测和启动硬件）、启动阶段（将boot loader载入内存执行、启动操作系统）、BIOS运行时服务阶段（提供基本的运行时服务）。 本文中的CBS组件只保留开机自检阶段，在该阶段检测物理内存、启动硬件设备、识别fuzz目标设备，然后启动MIOPS服务器。 MIOPS服务器接收设备控制客户端（DCC）发送的包含IO操作的请求（称其为MIOA请求，即Memory IO Access请求），并执行IO操作。MIOPS和DCC之间使用虚拟串口通信。 一个MIOA请求使用伪代码的形式定义，如：

当MIOPS接收到MIOA请求时，会解析该请求，并执行IO操作，解析过程很像QEMU的qtest框架，示例代码如：

2) 设备控制客户端（称其为DCC组件） a) 功能：DCC运行在host端。主要负责启动VMM进程，解析AFL-fuzz生成的DCD（Device Control Data）至MIOA请求，将MIOA请求发送至MIOPS服务器。 b) 实现：定义和解析DCD文件。 以USB XHCI设备为例，DCD文件如下：

该DCD文件包含两个USB XHCI命令，分别以命令id 0x0B和0x0C开头（绿色下划线），接下来的内容为该命令的参数（红色下划线）。 对应的结构体定义如下：

再举一个例子，软盘设备的DCD格式定义如下：

如：

将会解析为以下MIOA请求（0x3f5为软盘控制器的IO端口号）：

上面这个例子比较简单，但有一些命令的翻译过程会更复杂。比如在USB XHCI的MIOA请求生成的时候需要查看USB XHCI的标准，同时也需要额外属性，比如XHCI命令队列映射的物理内存地址，XHCI事件队列映射的物理内存地址等，这些信息需要在初始化USB XHCI设备时获取。 3) 集成的AFL

简化后的AFL相关架构如上图。 a) 插桩：若VMM开源，使用AFL-gcc编译目标虚拟设备的源码；若VMM不开源，逆向二进制代码，对目标虚拟设备二进制指令进行patch。 b) 输入：使用DCD文件作为输入，使用AFL的算法随机变异。

使用该系统fuzz QEMU的磁盘控制器，重新发现了Venom漏洞（CVE-2015-3456）。过程如下： a) 用afl-gcc编译fdc.c，修改rules.mak文件如下：

b) 定义输入文件格式：

c) 准备了30个输入样例。 d) 开启DCC客户端，DCC开启VMM和MIOPS，创建管道用于通信：

e) 开始fuzz：

对QEMU2.3版本，在8G内存，4核CPU上运行，约1.5小时后复现了Venom漏洞。

② HYPER-CUBE: High-Dimensional Hypervisor Fuzzing(2020)[2][3] Sergej Schumilo, Cornelius Aschermann, Ali Abbasi, Simon W¨orner and Thorsten Holz, NDSS 2020 本文提出了HYPER-CUBE，一个针对Hypervisor的fuzz工具，可以适用于开源和闭源的Hypervisor。本方法基于定制的操作系统，部署了一个定制的字节码解释器，与其他fuzzer不同的是，本系统不采用覆盖率引导的fuzz方式，但能够达到高吞吐、高效率和高代码覆盖率。该系统可以在5分钟之内重新发现Venom漏洞（CVE-2015-3456），一共发现了54个bug，获得43个CVE号。 系统由以下几个部分组成： a) 定制的guest操作系统：HYPER-CUBE OS。 b) guest内运行的字节码解释器：TESSERACT。 c) host上运行的一组工具，用于向TESSERACT发送字节码、语料最小化、监控guest行为等。

1) HYPER-CUBE OS a) 功能： 定制的HYPER-CUBE OS可以支持从GRUB等常见的bootloader启动。该OS有两个主要功能：内存管理和设备枚举。设备枚举和启动TESSERACT需要申请一段内存，OS的内存管理模块分配了一块堆内存用于申请和使用；除此之外，其他交互接口有时会使用物理内存，OS在虚拟地址空间内创建了一对一的线性物理地址映射。 HYPER-CUBE OS最重要的功能是为fuzzing列举不同的接口，如图中所示，有PCI设备、ISA设备等。 b) 实现： -启动阶段 不同的bootloader加载OS内核的流程不同，为了忽略它们之间的差别，本文使用multiboot2。 初始化中断方面，为了能与外部硬件异步交互，使用了PIC（Programmable Interrupt Controller）和APIC（Advanced Programmable Interrupt Controller）。在启动阶段，HYPER-CUBE OS对PIC和APIC进行配置，安装必需的中断和异常处理句柄。 -内存管理 本文定制了一个堆内存分配器，允许任务在一次分配一个页面，这个设计能够简化实现的复杂性、减少堆上内存碎片，还提高了系统的鲁棒性，但是缺点在于增加了内存消耗。HYPER-CUBE OS在设备列举和与TESSERACT交互中内存分配次数较少，所以这个缺点在实际应用中并不明显。 -设备枚举 像PCI设备、APIC或者HPET（High Precision Event Timer）会将内部寄存器映射至物理地址，系统列举出所有的MMIO和端口IO的地址范围。 2) TESSERACT TESSERACT是一个指令集解释器。提供的操作码句柄如：

TESSERACT的字节码格式定义使用类文本的风格。有两种方式向fuzzer输入字节码指令：如果在host端没有字节码输入，TESSERACT使用伪随机数生成器来生成随机的指令。或者在OS中内置字节码字符串。此外，系统还提供了语料最小化的脚本。

③ VDF: Targeted Evolutionary Fuzz Testing of Virtual Devices(2017)[4] Andrew Henderson, Heng Yin, Guang Jin, Hao Han, and Hongmei Deng, RAID 2017 本文提出了工具VDF（Virtual Device Fuzzer），用于对QEMU模拟的硬件设备进行模糊测试。 Fuzz虚拟设备的难度在于设备是有“状态”的，每一个设备需要在初始化之后才能正常工作，正常工作时的行为也有固定的模式，因此直接发送随机的变异数据效果并不好。VDF使用“录制-重放”（Record and Replay）方法，首先收集设备的初始化行为和正常工作的行为，再对正常的工作行为进行变异后重放。VDF工具由三部分组成： 1） 录制。 在QEMU代码中增加的一段录制代码，用于记录虚拟设备的IO读写行为，在guest OS启动，虚拟设备初始化，以及设备正常工作时，VDF会记录guest对虚拟设备控制寄存器的读写操作，生成一个设备行为的数据样例。数据样例包括初始化样例和正常工作的种子样例两部分。VDF定义了录制样本的格式。

2） 插桩及种子变异。 a) 插桩：VDF的插桩功能基于AFL开发，可以做到有选择性的插桩，只对我们关心的虚拟设备部分代码进行插桩。该功能的实现在于在AFL编译工具链中添加了一个编译参数，只有带有该flag的源代码文件才会被插桩。

b) 语料最小化：测试样例的预处理过程有三步：去掉不合法的样本、去掉crash/hang之后的样本、去掉复现crash/hang非必要条件的样本。

3） 重放。基于QEMU的Qtest单元测试框架开发了一个新的QEMU accelerator，大概在QEMU中加入了850行代码，该工具将Qtest的client和server合并到一起，能够使VDF工具在事件发生时直接进行重放样本，节省了进程间通信的时间。

效果：对18个虚拟设备进行fuzz，在其中6个虚拟设备中发现了超过一千个crash，报了一些CVE。代码覆盖率平均约62.32%。

使用QEMU纯软件模拟的方式构建虚拟机的性能较差，云环境中一般会使用QEMU-KVM方案。KVM基于硬件虚拟化辅助技术（如Intel VT-x、AMD-V），可以提供CPU、内存的虚拟化，但IO硬件设备还是由QEMU来模拟的，效率并不高。为了解决这个问题，Rusty Russell开发了virtio框架，virtio是半虚拟化设备，需要在guest中安装对应的驱动程序。virtio在guest和host之间使用共享内存vring结构传递IO数据，极大提高了效率和吞吐率。关于virtio的实现细节在此不再详述，可以参考Rusty Russell的paper[5]。

④ 使用AFL fuzz virtio-blk(2019)[6] Virtio Device Fuzzing by Dmitrii Stepanov, KVM Forum 2019 virtio-blk是virtio虚拟存储设备的一种实现，使用QEMU作为后端。SPDK是由intel发起的虚拟化存储优化框架，替代了QEMU的功能，使用vhost用户态程序作为后端。本演讲主要分享了使用AFL对QEMU virtio虚拟化存储后端进行模糊测试。实现方式为在AFL和QEMU之间增加一个软件代理。AFL和代理之间使用Unix socket通信，QEMU和代理之间使用Qtest框架以及QMP协议通信。

1）方法 a) 插桩：使用afl-clang对QEMU中virtio部分代码进行插桩。 b) QEMU状态：AFL fork() QEMU，QEMU进程的运行状态将直接可以由AFL获得。 c) 输入：首先尝试使用guest存储设备的内存进行随机变异，缺点是效率低下，每次都需要重新初始化guest内存；其次使用现有的API修改virtio共享内存的descriptor table，速度快但是没有触及到可能崩溃的路径；最终使用的方法是，对存储设备协议和virtio共享内存的descriptor table都进行随机变异，这个方法在代码覆盖率和效率上都比较好。

2）效果：发现了一些crash和CVE。 3）实现：代码见github[7] 对QEMU修改： a. virtio-blk代码增加AFL fuzz支持 b. tests/下增加基于Qtest框架的test_proxy程序 对AFL的修改： 增加与test_proxy通信的unix socket模块。

⑤ Qtest结合libfuzzer对QEMU设备进行FUZZ(2020) QEMU5.0.0版本主分支增加了部分fuzz代码。代码源于2019年google的暑期项目[8]，作者是Alexander Oleinik。这部分fuzz代码基于qtest和libfuzzer。qtest是QEMU的单元测试框架，libfuzzer是google开发的一个覆盖率引导的fuzz引擎。本部分首先介绍qtest，然后介绍qtest和libfuzzer结合对QEMU进行模糊测试。 （一） Qtest——QEMU的单元测试框架

Qtest是QEMU代码主分支内的一个用于做单元测试的框架，主要用作QEMU模拟的硬件设备的开发人员进行单元测试，源码在qemu/tests/qtest目录。[9][10][11] Qtest由两部分组成：Qtest client和Qtest server。client和server之间通过unix socket通信，Qtest支持发送PIO、MMIO、中断、QMP指令等。 1.Qtest client。 qtest client是我们编写的测试某个设备的测试程序，按照从底层至上层的封装顺序，它基于： -glib单元测试框架（2007）。[12] -libqtest（2012）：对glib test做封装，第一版QEMU的单元测试框架 -libqos（2012）：增加PCI的封装、内存分配，为编写qtest样例提供了一个小的系统库[13][14] -qgraph（2018 sinceQEMU4.0）：支持多架构；把系统、设备、API抽象成图[15] 一个简单的例子：

写一个新的测试程序的步骤： 1) 编写测试代码tests/qtest/foo-test.c 2) 在tests/qtest/Makefile.include增加新的源代码：

3) 编译测试程序

4) 运行测试程序：

2.Qtest server。 qtest server注册为QEMU的一种accelerator，在启动QEMU时添加以下参数：

正如TCG、KVM也是QEMU的accelerator，qtest承担的角色与他们类似。在普通使用场景中（如图左），VCPU和虚拟硬件交互；在qtest使用场景中，qtest直接与虚拟硬件交互（如图右）。[13]

-qtest server的启动流程：

-代码分析： 在libqtest.c中，qtest_init_without_qmp_handshake()启动QEMU作为子进程，在QEMU的启动主函数vl.c中，设置accelerator为qtest将会调用qtest_init()，qtest_init()在qtest.c中定义。 tests/libqos/libqtest.c为client端部分，将以以下qtest参数启动QEMU:

vl.c是QEMU启动的入口代码，解析QEMU命令行参数:

qtest_init()初始化qtest server：

qtest_init()定义在qtest.c中。 qtest.c中创建了一个qtest的字符设备，绑定了几个handler：

函数原型为：

对应的IOReadHandler为qtest_read；IOEventHandler为qtest_event。

qtest_event()中有两种case：CHR_EVENT_OPENED和CHR_EVENT_CLOSED，定义开启和关闭字符设备时的操作，将log写入qtest log文件中。

（二）使用qtest+libfuzzer对QEMU设备进行模糊测试 实现方式为：在qgraph库的基础上，增加libfuzzer部分代码。关于libfuzzer网上有很多资料[16]，在此不再展开叙述。 1.代码实现 代码路径在tests/qtest/fuzz，在fuzz.c中定义了libfuzzer的入口函数：

2.使用 1）安装编译

2）运行：

目前支持8个fuzz目标,如图所示。 3）对virtio-net-socket进行fuzz： 设置-print_final_stats=1输出最终统计数据，-max_total_time设置fuzz运行时间（秒）。

4） 运行截图

5） 精简语料集： 增加-merge=1参数，CORPUS_MIN为精简后的语料路径，CORPUS为原语料路径。

3.增加生成代码覆盖率报告 生成代码覆盖率报告有利于清晰了解fuzz状态，QEMU主分支中fuzz部分目前还没有这个功能，因此笔者自行添加了该功能，方法如下： 1）编译时添加-fprofile-instr-generate -fcoverage-mapping参数。该参数用于增加clang的代码覆盖率支持。[17]

然后编译运行：

2） 运行后会在当前目录下生成一个default.profraw文件。 3） 使用llvm工具将profraw文件转换成profdata格式：

4） 使用llvm-cov工具查看代码覆盖率报告：

5） 输出代码覆盖率报告：

在前面提到的virtio框架的基础上，vhost将virtio后端从QEMU改为内核，在内核中加入了vhost模块，进一步减少用户态和内核态之间的切换，使得IO数据可以在内核态得到处理，进一步提高IO吞吐率和效率。（PS：后来为了适配Open vSwitch等虚拟交换机软件等SDN场景，提高效率，又将virtio后端重新从内核移到了用户态，也就是vhost-user和DPDK，本文不再详细讨论）⑥使用syzkaller对vhost内核模块进行模糊测试(2018) syzkaller是google安全研究人员开发的基于代码覆盖率的内核API模糊测试工具，用户可以通过自定义描述脚本对内核的系统调用进行fuzz。[18]vhost内核模块也可以使用suzkaller进行fuzz。在vhost内核模块的CVE中，就有使用syzkaller的自动化fuzz系统syzbot发现的漏洞。[19] 关于syzkaller，在此仅简单叙述。官方文档中的架构图如下：

syzkaller主要由三部分组成： 1)syz-manager:运行在host宿主机上，用于开启、监控和重启虚拟机，在虚拟机中启动syz-fuzzer进程，管理语料及crash。 2)syz-fuzzer:运行在guest虚拟机中，负责fuzz进程的生成输入、变异、语料最小化等，把触发新代码覆盖的输入通过RPC回传给syz-manager。在这个过程中，会开启syz-executor进程。 3)syz-executor:执行一次输入，把结果回传。每个输入都是一串系统调用（使用syzkaller的格式定义）。

此外，收集内核的代码覆盖率需要内核支持kcov。在Linux内核版本4.6中开始支持kcov，可以通过配置内核参数来启用。对于较旧版本的内核,需要在内核中添加KCOV覆盖率代码。

-syzbot syzbot是一个基于syzkaller的自动化fuzz系统。它能持续不停的运行syzkaller，对linux内核各个分支进行模糊测试，自动报告crash，作者是google的Dmitry Vyukov。[20]syzbot还会监控bug的当前状态（是否已被修复等），监测对于bug的patch是否有效，完成发现-报告-复现-修复的整个流程。 下图为syzbot报告的vhost内核模块的漏洞。

[1] When virtualization encounters AFLhttps://www.blackhat.com/docs/eu-16/materials/eu-16-Li-When-Virtualization-Encounters-AFL-A-Portable-Virtual-Device-Fuzzing-Framework-With-AFL.pdf [2] HYPER-CUBE:High-Dimensional Hypervisor Fuzzinghttps://www.ei.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2020/02/07/Hyper-Cube-NDSS20.pdf [3] Slides: HYPER-CUBE:High-Dimensional Hypervisor Fuzzinghttps://www.ndss-symposium.org/wp-content/uploads/23096-slides.pdf [4] VDF: Targeted Evolutionary Fuzz Testing of Virtual Deviceshttps://link.springer.com/chapter/10.1007/978-3-319-66332-6_1 [5] virtio: Towards a De-Facto Standard For Virtual I/O Devices [6] [2019] Virtio Device Fuzzing by Dmitrii Stepanovhttps://www.youtube.com/watch?v=dk6SUD8ovXw [7] Virtio Device Fuzzing by Dmitrii Stepanov on Githubhttps://github.com/yandex/qemu/commit/3b82cea6af0f1640b81966e7200a816e4198340b [8] [Qemu-devel] [RFC 00/19] Add virtual device fuzzing supporthttps://lists.sr.ht/~philmd/qemu/%3C20190725032321.12721-1-alxndr%40bu.edu%3E [9] Features/QTesthttps://wiki.qemu.org/Features/QTest [10] QEMU on GitHubhttps://github.com/qemu/qemu [11] Testing in QEMUhttps://github.com/qemu/qemu/blob/master/docs/devel/testing.rst [12] 理解 GLib 的单元测试框架https://segmentfault.com/a/1190000003996312 [13] Integrated Testing in QEMU- An overview of qtest and qemu-testhttps://www.linux-kvm.org/images/8/89/2012-forum-Liguori-qtest.pdf [14] Testing QEMU emulated devices using qtesthttps://www.linux-kvm.org/images/4/43/03×09-TestingQEMU.pdf [15] Features/qtest driver frameworkhttps://wiki.qemu.org/Features/qtest_driver_framework [16] libFuzzer Tutorialhttps://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md [17] Clang 8 documentationhttps://releases.llvm.org/8.0.0/tools/clang/docs/SourceBasedCodeCoverage.html [18] syzkaller – kernel fuzzerhttps://github.com/google/syzkaller [19] KASAN: use-after-free Read in vhost_transport_send_pkt – CVE-2018-14625https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039 [20] syzbothttps://syzkaller.appspot.com/

本文由360云安全原创发布

转载，请参考转载声明，注明出处： https://www.anquanke.com/post/id/211930

安全客 - 有思想的安全新媒体

本文转载自:

如若转载,请注明出处：

安全客 - 有思想的安全新媒体